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Abstract. The authors of this paper have been working in a research and 
development project called TranSAFE-Alp under the EU Alpine Space Pro- 
gram since 20111 J ITES (Joint Integrated ICT-Technology service for 
Emergency and Security management) is one of the main outputs of the 
TranSAFE-Alp project. The main goal of J ITES is to facilitate the coordina- 
tion and management of transnational actions to be undertaken when a 
catastrophe (natural or manmade) event take place in the transport net- 
work of alpine region. This paper demonstrates a significant part (hereafter 
referred as J ITES-Geo) of thej ITES system which has been developed sole- 
ly for transport crisis management with a goal to improve the management 
of transport emergency cases. The main concern while developing J ITES- 
Geo was to explore the prospects of Geo Web Services (GWS) (section 2) 
technologies especially the Web Processing Service (WPS) and with a basic 
question: whether it is possible to make a system like J ITES-Geo mainly 
using GWS or not? The authors, at this stage, successfully designed and 
implemented some WPS which in combination with other GWS like Web 
Map Service (WMS), Web Feature Service (WFS), and Transactional Web 
Feature Service (WFS-T) form the base of the J ITES system. Therefore, the 
main aim of this paper is to express J ITES-Geo covering the aspects like 
system design, architecture, transport disaster scenarios and last but not 
least some use cases of the system. The paper is therefore structured in the 
way that the next sections after introduction include a short discussion of 
GWS followed by state of the art of GWS in disaster management. Thereaf- 
ter, some disaster scenarios in alpine transport network are revealed in 
short and finally thej ITES is demonstrated followed by some conclusions. 

Keywords: Geo Web Services, Transport Crisis M anagement, Routing 



1 http://www.transafe-alp.eu/ (last accessed on April 2, 20 13) 



1. Introduction 



Geographic Information Systems (GIS) have been used in various domains 
of disaster management for many years and already been proved as valua- 
ble tools for decision support and management of disaster events (Konecny 
& Reinhardt 2010). Geo Web Services (GWS), which are relatively new ex- 
tents of Gl S, are making their headway faster than ever, allowing us to use 
various type of geo-data and geo- processing functionalities from different 
sources in a system independent environment in a standard way and with 
low cost and resources. These remarkable features of GWS embolden the 
authors to build a GWS based prototype application (J ITES-Geo 2 ) for 
transport emergency management. J ITES-Geo is in fact a major part of the 
J ITES system which is a prime output of the project TranSAFE-Alp. The 
present paper demonstrates the development of J ITES-Geo based on Geo 
Web Services for transport crisis management with a goal to improve the 
management of transport emergency cases within the frame of a project 
"TranSAFE-Alp" under Alpine Space Program. The objectives of the project 
as well as the requirements for Geo Web Services are outlined in Reinhardt 
etal.(2013). 

The intention was to use open-source software only, and to create a brows- 
er-based application which can be accessed from anywhere using a stand- 
ard browser. J ITES-Geo is merely a prototype application, purposively de- 
veloped to examine tools that are available to use in a disaster management 
system under the above mentioned circumstances. The application is, 
therefore, built with different geo web services like Web Map Service 
(WMS), Web Feature Service (WFS), Transactional Web Feature Service 
(WFS-T) and Web Processing Service (WPS) in combination with the 
OpenLayers library. However, it is especially the Web Processing Service 
(WPS) which obtains a great importance in our work, as it allows us to call 
geospatial operations as a service. J ITES-Geo introduces a new form of 
routing geo- processing function which differs from the traditional routing 
processes in a way that it allows routing considering the safest, fastest or 
shortest path. Routing in combination e.g. safest and fastest or safest and 
shortest is also possible in J ITES-Geo. 

The foremost purpose of this paper is to descri be some basic features of the 
J ITES as well as details of J ITES-Geo covering the aspects like system de- 
sign, architecture, transport disaster scenarios and last but not least some 
use cases of the system. 



2 I n this paper the authors tried to reveal a major part of the J ITES which is mostly GWS 
based.The authors select a pseudo name: J ITES-Geo to refer that part of J ITES in this paper. 



2. Related Works 



There have been a couple of implementations of GWS already in crisis 
management. For example, Maiyo et al. (2010) examined the importance of 
GWS in post disaster mapping, as tool collaboration not only for disaster 
management agencies, but also for user generated content. They have de- 
veloped a prototype system where all these information are delivered and 
integrated via GWS. Their system has two components, the first one is the 
thin client, which is based on OpenLayers API just like our client, and it is 
used for adding geotagged notes, pictures, etc. and is available for every 
user. The other component, the thick client is used for more complex tasks 
such as the production of post disaster maps. 

Advantages of the GWS are also well represented in the study "Decision 
Support for Tsunami Early Warning in Indonesia" (Raapeet al. 2010). The 
authors of that study showed that GWS can provide a unified access to spa- 
tial data, which can be used in any kind of clients. This interoperability is 
also used in another early warning system study (Casola et al. 2010), where 
two main aspects of the Geo Web Services are used: the ability to elaborate 
data from heterogeneous sources and to manage data sources. 

The WPS technology has been also used in crisis management, for example 
in the study "Multi-Criteria Evaluation for Emergency Management" (M Cil- 
ler et al. 2010). The authors have developed and implemented OpenGIS 
web service architecture for multi criteria evaluation (MCE). The spatially 
enabled MCE service is implemented as a WPS to ensure the potential for 
integration with other frameworks for spatial decision support. 



3. Geo Web Services 

Geo Web Services are a special form of Web Service, which are specially 
designed for spatial data. They provide access to geographic information 
and enable calculations for spatial content. GWS provide the ability to per- 
form complex calculations on geometry of the spatial objects. GWS connect 
information, data and functionality from different resources in a platform 
independent way. 

3.1 . About OGC Geo Web Services 

The Open Geospatial Consortium (OGC) as widely known in our communi- 
ty is an international consortium of 480 members with the aim to develop 
different interface standards in the geo-enabled web 3 . The OGC develops 



3 http:/ / www.openqeospati al .org/ oqc (last accessed on April 2, 20 B) 



different standards for Geo Web Service. Three major standard services of 
OGC that related to this paper are shortly described in the foil owing: 

WMS (Web Map Service): renders maps with spatial content dynamically 
from geographic information. Map is understood as the portrayal of geo- 
graphic information as a digital image file which is suitable to be displayed 
on a computer screen. The maps produced by a WMS are generally ren- 
dered in a raster graphic format like PNG, J PEG or GeoTiff as well as in a 
vector based format such as SVG (Open Geospatial Consortium I nc. 2006) 

WFS (Web Feature Service): The OGC Web Feature Service allows a client 
to retrieve and update geospatial data encoded in Geography M arkup Lan- 
guage (GM L) from multiple Web Feature Services. While the basic version 
of WFS solely provides data, the WFS-T (Web Feature Service Transaction- 
al) also allows the modification (insert update, delete) of vector data (Open 
Geospatial Consortium I nc. 2005). 

WPS (Web Processing Service): All the web service standards presented so 
far are dedicated to the provision of data, the WPS however has the aim to 
define different processes and use them to process geodata online (Open 
Geospatial Consortium I nc. 2007). 



4. Transport Emergency Scenarios in Alpine Region 

The probability of a natural hazard and its severity is growing nowadays 
due to the growth of the population, especially in urban areas, and the sus- 
ceptibility of the modern technologies (Berz 2009). It is especially signifi- 
cant in the alpine region, where in the past landslides and avalanches af- 
fected mostly agricultural areas, whereas nowadays settlements are found 
everywhere and also important infrastructures are at risk (Greminger 
2003). Among the infrastructures transport network is one of the signifi- 
cant one since interruption of a transport network triggers cascading effects 
on the economy and lifestyle. The growing number and severity of catastro- 
phes (both natural and manmade) on transport network point out a need of 
very well organized, also at a cross-border scale interoperable monitoring 
and management system to be able to organize effective rescue, damage 
control and management operations. 

The J ITES has been designed in a way that it offers guidelines of control 
and management of any disaster event in the transport network to the re- 
spective authority (most of the time transport control center). I n order to 
implement this functionality, some real disaster scenarios including the 
disaster events and its management procedure have been collected from 
different transport control centers. The aim was to integrate best available 



emergency plans in the systems. As an initial attempt scenarios for some 
major real disaster events (e.g. fire in tunnel, flood etc.) have been collected 
and integrated into the J ITES for the pilot actions. Figure 1 shows a gross 
overvi ew of a f i re event scenari o i n a tunnel . 
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Figure! Scenario of a fire event in Frej us tunnel 



The scenario shown in fig.l is defined (presented in an internal meeting of 
TranSAFE-Alp project) by one of the partner in TranSAFE-Alp project 
called SITAF-spa together with Province of Turin, Turin Civil Protection 



and Polytecnique University of Turin. The scenario is based on a fire event 
in Frejus tunnel (a tunnel between Italy and France). Figure 1 shows that 
access to the tunnel get closed by the authority immediately after a fire 
event occurs. Thereafter, different partners get involved to solve the event 
and in parallel users are notified and guided through different media. Once 
the event is solved the tunnel gets open and users are notified. 

5. The JITES-Geo 

TheJ ITES-Geo which is a prime part of J ITES can be seen as a web based 
application capable of doing geo-editing, geo- processing and geo- 
visualization in the domain of transport emergency management. 

5.1. Some pre-requisites 

J ITES-Geo should be based on GWS with special emphasis on the WPS. 
The intention was to use open-source software only, and to create a brows- 
er-based application which can be accessed from anywhere using a stand- 
ard browser. Another important issue was to ensure the capability of data 
retrieval from various sources via internet so that the transport control cen- 
ters do not have to wait for the data and can avoid data conversion process- 
es. This pre-requisite ensures the necessary data to be available automati- 
cal ly to the control center i n case of emergency so that they can begi n to act 
immediately. Another prerequisite was to provide guidance to the control 
centers in the form of tasks to do' in case of emergency. Also a spatial rep- 
resentation of the emergency units with the ability to find the nearest ones 
was needed. And the final important demand was a routing function capa- 
bleof calculating alternative fastest, shortest and safest routes. 

5.2. System design 

The application is based solely on open source software, such as Post- 
greSQL, GeoServer and OpenLayers. The architecture (fig.2) of the applica- 
tion can be compared with the typical three tier web architecture consisting 
of a data ti er, a busi ness I ogi c ti er and a cl i ent ti er . 

The data tier consists of databases, in this case spatial database. The data- 
base software PostgreSQL 4 and its spatial extension PostGIS 5 has been 
used to store the geo-spatial data. The raw data (transport network, vulner- 



4 PostgreSQL website: http:// www.postqresql .org/ (last accessed on February 6, 2013). 

5 PostGI S website: http://postqis.net/ (Last accessed on February 6, 2013). 



ability information etc.), which was originally in shape file format is loaded 
in this database system, and later on accessed with the help of GeoServer. 
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Figure 2. Architecture of J ITES-Geo 



GeoServer 6 has been used in the business logic tier since it is free and offers 
WMS, WFS and some basic WPS. The main function of GeoServer is to re- 
ceive requests from the client, process the request through a connection 
with the data store and finally send back the results to the client. The Ge- 
oServer processes different request for the different Geo Web Services 
(WMS, WFS, etc.) within it. 

The last tier is the browser based client tier, which is accomplished by 
Open Layers 7 , an open-source library designed to easily visualize geospatial 
data. Service requests are made with the client and sent to the GeoServer. 
The browser based client is also used for visualizing the results sent by Ge- 
oServer and the data editi ng. 

5.3. Data 

Datasets from different sources (fig.2) have been used, demonstrating one 
of the biggest advantages of a web service based application. The road net- 
work which is the main dataset, that composes the PostgreSQL database, is 
provided by the EU project: Alpcheck2 8 . The data contains road network 
with traffic information. 



6 GeoServer website: http://qeoserver.orq/ (last accessed on February 6, 20 13). 

7 OpenLayers website: http:/ / open I avers.org/ (Last accessed on February 6, 2013). 

8 For more information, go to: http://www.alpcheck2.eu/ (Last accessed on April 2, 2013) 



The vulnerability (with reference to natural hazards) information was gath- 
ered and processed by a project partner called AISCAT 9 . The vulnerability 
information is divided into seven different categories. The probability of 
each category of natural disaster is assigned to each segment of the road. As 
real data was not yet available for demonstrating the emergency units, we 
have randomly generated some arbitrary locations. The locations are point 
feature and considered as helicopter rescue units. 



6. Use Cases 

J ITES is designed to makethe work of the operator easier. It provides guid- 
ance for each step needed to be undertaken in order to manage any disaster 
event in the road transport network. The main responsible project partner 
for the development of J ITES is Fondazione Bruno Kessler (FBKP whereas 
J ITES-Geo part is developed by the authors. The following flow chart (fig. 
3) (some parts of this flow chart are collected from a presentation of FBK in 
an internal project meeting) shows the main steps of this workflow whereas 
figure 4 shows the background system processes of J ITES-Geo. The follow- 
ing sections describe each steps of the workflow of J ITES (fig. 3) with cross 
reference to the background system processes (fig. 4) where applicable. 

6.1 . Emergency scenario selection 

When a disaster occurs, the first step is to determine the type of the disas- 
ter. J ITES contains a knowledge base about almost every possible emergen- 
cy scenario in road transport network including their management tech- 
niques and phases (section 3). Therefore, J ITES is able to provide the best 
protocol a certain disaster event to the disaster management authority 
within a couple of seconds. This is important because when a disaster real- 
ly occurs; there is no time to figure out which protocol to use. First the gen- 
eral type of disaster has to be decided, i .e. whether it is an accident, a fi re or 
a natural hazard (fig.3 B). I n the next step the type of this event has to be 
determined more precisely, e.g. if it is a fire, is it in a tunnel, in an open 
road or in the surrounding? Though it has been tried to cover all possible 
disaster scenarios in J ITES knowledgebase but there are always chances 
that something could happen which exceed the knowledgebase. Therefore, 
options for defining new disaster scenarios are also integrated in J ITES. 



9 More information of the partner can be found in the web link: 
http:/ / www. ai scat. it/engli sh/ i ndex. htm (Last accessed on April 2, 2013) 

10 http://www.fbk.eu/ for more information. (Last accessed on April 2, 20 13) 



Fire in tunnel I 



Fire on open 
road 



Contro 
center is 
notified 








•f Avalanche ] 




Select road 
segment 



Find and call 
nearest 

emergency units 



Create 
polygon 



Flood 




Disaster management phases 
according to the scenario 



71 

?s 




f Notification:^ 
event is 
finished 




Figure 3. Workflow for managi ng a disaster event through J ITES 
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Figure 4. Sequence diagram of J ITES-Geo 



6.2. Affected area determination 

Dependi ng on the type of the disaster there are two possi bi I ities to mark the 
affected area. If it is a local event the control center sets the location of the 
event as a point (fig.3 C and fig.4 B). If it is a bigger area expanded disaster, 
such as flood, it is possible to request current aerial or satellite images from 
the GM ES U program. This image is embedded in the system via WMS ser- 



u GMES is an earth observation program headed by European Commission (EC). More de- 
tail can be found in: http:/ / www.copern i cus.eu/ i ndex. php (Last accessed on April 4, 2013) 



vice, which makes the process easier and faster. The operator locates the 
disaster on the satellite image and draws its boundaries in the J ITES-Geo. 
This is then saved with WFS-T in the database for further processing and is 
deleted when the event is over. At both methods the road network is inter- 
sected with the event location and the underlying roads are marked as una- 
vailable. This is important for the rescue units and for traffic rerouting. 

6.3. Finding nearest emergency units 

The emergency units have to be notified once the disaster event is located. A 
nearest emergency unit finder function is therefore included in thej ITES- 
Geo. The function enables the user to locate any emergency unit closest to 
the disaster area (fig.3 D and fig.4 D). For this a pre-programmed WPS 
(gs:Nearest) offered by the GeoServer is called. The nearest emergency unit 
finder function works in a way that when one of the disaster areas is select- 
ed, it calculates the center point of this area and then finds the nearest 
emergency unit to it (fig. 5). These units then are notified with the coordi- 
nates of the d i saster I ocati on . 




Figure 5. The nearest emergency unit is highlighted 



6.4. Alternative route generation 

One of the main tasks in emergency traffic management is to provide alter- 
native routes for traffic when a disaster occurs and a road becomes unavail- 
able (fig.3 E). To accomplish this in J ITES-Geo, the authors have imple- 
mented the Dijkstra algorithm, provided by pgRouting 12 (fig.4 C). The 
Dijkstra algorithm calculates the most economic path between two nodes 
consi deri ng the cost of the path (f i g. 6) . 



12 pgRouting extends the PostGI S/ PostgreSQL database to provide geospatial routing func- 
tionality. More detail can be found in: http:// pgrouti ng.org/ ((Last accessed on April 4, 2013) 




Figure 6. Alternative route consider i ng the cost of path is shortest 



The cost of the path can be generated from various type of weights al located 
to each edge of the road e.g. length of edge or travel time. J ITES-Geo offers 
three different options to from a route between two points of interest using 
three different weightage methods. The first option is the shortest route 
which is calculated simply by considering the edge length as weight. The 
disadvantage of this method is it does not consider the qual ity of the roads. 

The second option is based on travel time means a route could be formed 
considering the minimum required time of travel. I n this case weightage is 
assigned to each edge accordi ng to the travel ti me. The travel ti me for each 
edge is calculated from the length of the edge and the maximum allowed 
speed on that road segment. We chose the maximum speed because there 
were no data available regarding the average speed. Nevertheless, the max- 
i mum speed is j ust as sufficient as the average speed, because we only need 
this information to be able to compare the roads with each other. This op- 
tion is more suffi ci ent for rerouting the traffic, because in a situation where 
traffi c j ams have to be avoi ded ti me i s a cruci al factor (f i g. 7) . 




Figure 7, Difference between the shortest and fastest path 



The third option is called the most secure path. This method is considering 
the vulnerability information which was available to us. It is developed to 
be able to avoid the roads which are less vulnerable to natural hazards. It is 
mainly used for the rerouting of vehicles carrying dangerous goods. The 
operator chooses the type of the hazards that should be avoided (fig.8). 




Figure 8. Routes which would be affected by flood 



6.5. On-site problem solvation and status update in JITES 

At this stage the responsible control center along with the responsible active 
partners i .e. pol ice department fi re brigade etc. take i nitiati ves accordi ng to 
the instruction provided by J ITES to resolve the disaster event in site (fig. 3 
F). The instructions are retrieved from the disaster scenario knowledgebase 
and structured in different phases. Once a certain phase is accomplished 
the control center updates the status of that phase through the J ITES to 
share the information to all active partners. 

6.6. Close of event and notification 

Once the disaster event is resolved, the responsible control center should 
close the event in J ITES and notify all the relative partners (fig.3 G). I n ad- 
dition an activity log could be saved in the system for future reference. 



7. Conclusion 

We have presented an example how transport crisis management tools can 
be developed with geo web services and a browser- based client. We have 
tested a few functionalities, but our work reveals that the opportunity is 
even much higher. A wide range of geo- processing functions related to dis- 
aster management particularly transport disaster management can be im- 
plemented with the help of web processing services. The WPS has the ad- 
vantage that the functionalities can be accessed from remote servers; they 



do not need to be installed in the local system. Another advantage is that if 
the functionalities offered by a WPS provider are not sufficient the desired 
function can be added from another provider or could be extended by pro- 
gramming. 

The J ITES-Geo could be further extended by developing more functions 
useful for disaster and transport emergency management control centers. 
For example, future development might be carried out in the direction of 
route classification to be able to make difference between roads that are 
avail able for heavy vehicles and light vehicles. The risk of transporting dan- 
gerous goods would also have to be considered in routing process. Moreo- 
ver, more complex functionalities could be accomplished through chaining 
of web processing services or Business Process Execution Language (BPEL) 
(J uric et al. 2006) for example searching the suitable location for vehicle 
parki ng i n emergency case could not be served by one si ngle WPS. 
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